昨天在 Day 6 的結尾丟了一個問題：

如果 LLM 根本不知道公司的內部資料，它又要去哪裡找答案？

這個問題其實在 Day 1 系列簡介的時候就埋下了：使用者問的問題，LLM 常常根本不知道答案，因為那是公司內部的資料。

今天，我想正式回答這個問題。這也代表 Stage 1（LLM 基礎）在觀念上要告一段落了，準備正式進入 Stage 2（RAG）。

**一、LLM 的三個先天限制

在往下走之前，先把 LLM 目前擺脫不掉的三個限制講清楚：

1.知識截止日（Knowledge Cutoff）

模型訓練資料一定有個時間點，過了這個時間點發生的事情，它一律不知道。問它「今天股價多少」「昨天發布的新聞」，它答不出來，甚至會亂猜一個看起來合理的答案。

2. 不知道你的內部 / 私有資料

公司內部文件、SOP、客戶資料，本來就不可能出現在公開的訓練語料裡。這也是企業導入 LLM 時，第一個會撞到的牆。

3. 幻覺（Hallucination）

呼應 Day 2 提過的觀念：模型本質上是在做機率預測，不是真的理解或查證過內容。當它手上沒有資料依據時，它不會誠實地說「我不知道」，而是會一本正經地編一個答案出來。

這三個限制，其實是同一件事情的不同面向：

LLM 只會根據「訓練時看過的東西」做機率預測，它沒有辦法查證，也沒有辦法即時更新自己的知識。

二、直覺解法為什麼行不通：重新訓練 / Fine-tune

第一個直覺的想法通常是：那就把公司資料拿去訓練模型，不就解決了嗎？

理論上可行，但實務上有幾個問題：

成本高：訓練或微調模型需要大量運算資源，不是每間公司都能常態負擔
資料一變就要重訓：內部文件幾乎天天在更新，不可能每次資料一變動就重新訓練一次模型
知識更新的即時性差：訓練好的模型本質上是一份「靜態快照」，跟不上資料變化的速度
可稽核性差：答案是被「編碼進模型權重裡」的，很難追溯來源，也沒辦法標註引用出處

換句話說，Fine-tune 比較適合用來調整模型的「說話方式」或「特定任務的表現」，但不適合拿來當作「即時知識庫」使用。

三、RAG 的核心概念：不改模型，而是「先查資料再回答」

這就是 RAG（Retrieval-Augmented Generation，檢索增強生成） 要解決的問題。

核心的思路轉變是：

不是讓模型「記住」所有資料，而是在回答問題之前，先去資料庫裡「查」跟問題相關的資料，再把這些資料一起丟給模型參考。

用一個比較生活化的比喻來說：

LLM 就像一個很會寫作、口條也很好的新人，但他沒讀過公司內部的文件。 RAG 就像是讓他「開卷考」——不用死背所有東西，但考試前，你會先把公司的資料夾翻出來，讓他參考著寫答案。

模型本身完全沒有被改動，改變的是「回答問題之前，先給它看什麼資料」。

四、RAG 基本流程

一個最基本的 RAG 流程，大致長這樣：

1. 使用者提出問題
2. 把問題轉成向量（Embedding）
3. 到向量資料庫裡，檢索出跟問題最相關的資料片段
4. 把「原始問題」加上「檢索到的資料」，組合成新的 Prompt
5. 把這個新 Prompt 丟給 LLM，讓它根據提供的資料生成答案
6. 回傳答案給使用者，並可以附上引用來源

這裡的第 2 步「把問題轉成向量」，其實就是呼應 Day 3 講過的 Embedding 概念——每個 Token 會被轉換成一個高維度的數值向量，意義相近的內容，向量距離也會比較接近。RAG 檢索的原理，正是利用這個特性去比對「問題」跟「資料庫裡的內容」哪些語意最接近。

五、RAG 解決了什麼、還沒解決什麼

RAG 解決的問題很明確：

不用重新訓練模型，就能更新模型能參考的知識
資料異動只要更新資料庫，完全不用碰模型本身
答案可以附上來源，可稽核性大幅提升

但 RAG 不是萬靈丹，還有很多細節需要處理，例如：

1. 檢索品質不好，就是垃圾進垃圾出（Garbage in, garbage out）
2. 要怎麼把長文件切成適合檢索的片段（Chunking）？
3. Vector Database 要怎麼選？
4. 檢索出來的結果，要怎麼評估好壞？

這些問題，正是接下來 Day 8 到 Day 16 要一一拆解的內容。

小結

一句話總結今天的內容：

LLM 負責「表達」，RAG 負責「提供正確的知識」。

Stage 1 到這裡告一段落。明天（Day 8）開始，我們會正式進入 Stage 2，從 RAG 最基本的元件——Embedding、Chunking、Vector Database 選型（MongoDB / Neo4j）——開始動手實作。